-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework PluginRegistry API and introduce VersionMatchRule enum #1163
Conversation
10be7e4
to
6e29ee0
Compare
6e29ee0
to
35a14aa
Compare
35a14aa
to
fead832
Compare
This PR now focus only on the rework of the In the meantime I made greater changes to the The rework is not yet completely finished, but the overall direction is settled and I would like to gather feedback already. |
*/ | ||
@Deprecated(forRemoval = true, since = "3.19 (removal in 2026-09 or later)") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw. what do you think about mentioning the earliest removal date here?
I think it would help consumers to understand better when the actual removal will happen earliest.
public static Stream<IPluginModelBase> findModels(String id, String version, VersionMatchRule matchRule) { | ||
Version reference = version != null ? Version.valueOf(version) : null; | ||
return selectModels(id, version != null ? p -> matchRule.matches(VersionUtil.getVersion(p), reference) : null); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of having one overload of findModel(s)
that accepts a VersionRange
and one that accepts a version String plus a VersionMatchRule
we could also just provide one method with a VersionRange
.
With the new VersionMatchRule
one would then use
findModel("foo.bar", EQUIVALENT.rangeFor(version))
instead of
findModel("foo.bar", versionStr, EQUIVALENT)
Of course the level of convenience is also influenced by the fact if one has a Version
object or a version String
.
Maybe this justifies to keep both so in case one has a Version object the former solution can be used and if one has a version String
the latter approach is nicer.
I'm torn on this question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because there is more than just one difference as described above, I think it is fine to preserve this structure.
fead832
to
f6d15ec
Compare
7896430
to
4551e03
Compare
In general I think this rework is now ready, although there might be a few more minor adjustments necessary. So anybody interested in this change, please share your opinion as soon as possible. I have also evaluated the possibility to return |
176a783
to
0f3d38f
Compare
Besides replacing the Equinox resolver VersionRange by the OSGi's org.osgi.framework.VersionRange, this also removes the rarely used filter parameter from the findModel() methods. Instead of an array the new findModels() methods return a stream that can be filtered by the caller if desired and is sorted by descending plug-in version. In all cases plug-ins with null IPluginBase or ID are now discarded by all findModel() methods that accept plug-in id plus version specification (range or match-rule). Part of eclipse-pde#1069
0f3d38f
to
cbb7f76
Compare
Modernize the PluginRegistry API that contains the antiquated
org.eclipse.osgi.service.resolver.VersionRange
by providing alternatives using theorg.osgi.framework.VersionRange
and deprecating the existing methods for removal.In conjunction with that also mark
PluginRegistry.PluginFilter
as deprecated for removal since it is effectively aPredicate<IPluginModelBase>
and just use the latter in the new methods.This is currently an early draft to discuss the overall direction. Since the intention is to focus on the API callers of the now deprecated methods are not replaced in this PR. I'll do that in a follow-up.
About the API I'm also contemplating to further modernize the methods in
PluginRegistry
that now return a List to return a Stream instead. Then we could also save the filter arguments since callers can just filter the returned stream if desired.Furthermore I would also like to replace the integer and string constants in
IMatchRules
by a corresponding EnumVersionMatchRules
(or similar) that also provides method to obtain a predicate for a reference version that implements the literals matching rule or to obtain a correspondingVersionRange
from a reference version (which ever is needed).Part of #1069